home *** CD-ROM | disk | FTP | other *** search
/ SPACE 2 / SPACE - Library 2 - Volume 1.iso / games / 64 / general / gembug.txt < prev    next >
Text File  |  1986-10-16  |  39KB  |  925 lines
  1.  
  2.  
  3.        #11000-#GEM Bug List                                     Page -1-
  4.  
  5.  
  6.  
  7.       #: 11020 S2/GEM Support 04-Sep-86 01:13:17
  8.  
  9.  Fm: Tom Jeffries 73717,2261       To: SYSOP*Dave Groves 76703,4223
  10.       Here's a bug for which I still need a solution.  GEM does not always seem
  11.  to report the release of a mouse button.  I've tried evnt_multi(), vq_mouse(),
  12.  a  routine  that  steals  the  mouse  interrupt  and checks the buttons before
  13.  handing  things  back  to GEM, and a few other things and in all instances the
  14.  status  returned  is not always correct.  It is correct if you move the mouse,
  15.  which  leads me to think that the mouse packet doesn't always get sent (which,
  16.  of  course, would not be a GEM bug).  John Feagans at Atari said they were not
  17.  aware  of  this  problem;  however,  several other developers on the Atari BBS
  18.  reported the same thing.  It happens on the Desktop sometimes: you click on an
  19.  option  but  nothing  happens  until  you  move the mouse.  I hope someone has
  20.  solved this one.
  21.  
  22.  
  23.       #: 11023 S2/GEM Support 04-Sep-86 01:21:46
  24.  
  25.  Fm: Tom Jeffries 73717,2261       To: SYSOP*Dave Groves 76703,4223
  26.       Evnt_timer()  doesn't  always  happen.   I've never tried to find out any
  27.  details,  but  sometimes  you  just don't get a noticeable time delay when you
  28.  call the function.
  29.  
  30.  
  31.       #: 11041 S2/GEM Support 04-Sep-86 03:39:23
  32.  
  33.  Fm: Corey Cole 76224,66       To: Tom Jeffries 73717,2261
  34.       We've  run into several symptoms that appear to be manifestations of this
  35.  (mouse  state  change  not  being  reported back properly).  In particular, we
  36.  discovered  that  vq_mouse  often  reports  an out-of-date error status, while
  37.  evnt_multi  and evnt_mkstate "go into the tank" for a noticeable time (approx.
  38.  1-2  seconds,  perhaps  a  bit  less)  before  returning correct status.  This
  39.  applies  even when the "number of clicks" parameter is set to one (not looking
  40.  for  multiple clicks), and even if the mouse is instantly moved outside of the
  41.  mouse  click dither range.  We reported the latter to DRI at their GEM seminar
  42.  in  April  of 1985, but the problem still exists in version 1.2 of IBM PC GEM,
  43.  as well as on the ST.  -- Corey
  44.  
  45.  
  46.       #: 11048 S2/GEM Support 04-Sep-86 10:37:13
  47.  
  48.  Fm: Quack Computer Co., NM 75426,3451       To: SYSOP*Dave Groves 76703,4223
  49.       A  GEM bug : If a virtual floppy disk is installed after system start-up,
  50.  the  system  bombs  when  required to do virtual disk swapping.  Disk swapping
  51.  works fine if the floppies are installed on start-up, though.
  52.  
  53.  
  54.       #: 11053 S2/GEM Support 04-Sep-86 12:59:39
  55.  
  56.  Fm: Dan Moore 74035,243       To: Tom Jeffries 73717,2261
  57.       I can confirm the mouse packet DOES get sent since I have played with the
  58.  packet  handler.   I  think  the  "missed" release is in GEM or the GEM packet
  59.  handler.
  60.  
  61.  
  62.  
  63.  
  64.        #11000-#GEM Bug List                                     Page -1-
  65.  
  66.  
  67.  
  68.  
  69.        #11000-#GEM Bug List                                     Page -2-
  70.  
  71.  
  72.  
  73.       #: 11075 S2/GEM Support 04-Sep-86 23:06:47
  74.  
  75.  Fm: Tom Jeffries 73717,2261       To: Dan Moore 74035,243
  76.       Very  interesting.  That means it would be worth writing my own interrupt
  77.  routine and avoiding GEM.  I've been holding off because I thought it might be
  78.  in the hardware.  Thanks! Tom Jeffries
  79.  
  80.  
  81.       #: 11041 S2/GEM Support 04-Sep-86 03:39:23
  82.  
  83.  Fm: Corey Cole 76224,66       To: Tom Jeffries 73717,2261
  84.       We've  run into several symptoms that appear to be manifestations of this
  85.  (mouse  state  change  not  being  reported back properly).  In particular, we
  86.  discovered  that  vq_mouse  often  reports  an out-of-date error status, while
  87.  evnt_multi  and evnt_mkstate "go into the tank" for a noticeable time (approx.
  88.  1-2  seconds,  perhaps  a  bit  less)  before  returning correct status.  This
  89.  applies  even when the "number of clicks" parameter is set to one (not looking
  90.  for  multiple clicks), and even if the mouse is instantly moved outside of the
  91.  mouse  click dither range.  We reported the latter to DRI at their GEM seminar
  92.  in  April  of 1985, but the problem still exists in version 1.2 of IBM PC GEM,
  93.  as well as on the ST.  -- Corey
  94.  
  95.  
  96.       #: 11073 S2/GEM Support 04-Sep-86 23:04:18
  97.  
  98.  Fm: Tom Jeffries 73717,2261       To: Corey Cole 76224,66
  99.       Thanks, Corey.  If you ever find a solution please let me know.  I have a
  100.  situation  where  I'd  like  some  text to keep scrolling as long as the mouse
  101.  button  is  held  down  in a certain location, but because of this bug it will
  102.  sometimes keep scrolling after the button is released.  Not good.  Tom
  103.  
  104.  
  105.       #: 11068 S2/GEM Support 04-Sep-86 22:36:34
  106.  
  107.  Fm: Christopher F.  Chabris 73277,305       To: SYSOP*Dave Groves 76703,4223
  108.       Just to put in my two cents worth: I suggested to Tim Oren a few days ago
  109.  that  the  compendium  that we are now compiling include all types of ST bugs,
  110.  not just GEM ones.  Accordingly, I suggest that the GEMDOS bugs that have been
  111.  responsibly  documented  by Atari in the GEMDOS spec.  in DL7 be included here
  112.  for  the  benefit  of  non-registered developers who do not have access to the
  113.  manual.  Each function given there has a list of zero or more known bugs which
  114.  should be put in the list.-- Chris Chabris
  115.  
  116.  
  117.       #: 11061 S2/GEM Support 04-Sep-86 20:34:09
  118.  
  119.  Fm: Mark McCulley 72337,3500       To: Tim Oren
  120.       I  seem  to  remember  some  discussion  here  a  while back about nested
  121.  event_multi()  problems  and  problems that can occur if the message buffer is
  122.  not  cleared.   I  don't  remember  if the two problems were related.  Anybody
  123.  remember the essence of that discussion?
  124.  
  125.       What happens if you just ignore messages (assuming the event_multi is NOT
  126.  waiting on a message)?
  127.  
  128.  
  129.  
  130.        #11000-#GEM Bug List                                     Page -2-
  131.  
  132.  
  133.  
  134.  
  135.        #11000-#GEM Bug List                                     Page -3-
  136.  
  137.  
  138.  
  139.       #: 11063 S2/GEM Support 04-Sep-86 21:29:34
  140.  
  141.  Fm: Tim Oren 76703,202       To: CHUCK WALBOURN 73537,527
  142.       Chuck, first of all I don't have anything to do with RCS any more, having
  143.  left  DRI over a year ago.  As to Pascal, version 2.0 which will EVENTUALLY be
  144.  released  by  DRI/Atari does have hooks for Pascal, Fortran, and BASIC.  I put
  145.  them  in  before  I  left.   Unknown  trees are mainly used when a resource is
  146.  opened  and there isn't any definition file - then you retype them to whatever
  147.  you  want.  Or, you can make a tree an UNKNOWN if you want to leave a reminder
  148.  that it is odd in some way, and shouldn't normally be altered.  - Tim
  149.  
  150.  
  151.       #: 11105 S2/GEM Support 05-Sep-86 20:21:54
  152.  
  153.  Fm: Anker Berg-Sonne 72337,3211       To: SYSOP*Dave Groves 76703,4223
  154.       I  have  been  battling a really weird problem in EAS and VDI for quite a
  155.  while.   First  the  scenario.  I'm writing an editor that used GEM windows to
  156.  look  into  several disk files and use v_text() to write the text.  Everything
  157.  works  just fine until I resize the window manually with the mouse.  If I make
  158.  the  window  smaller  on  both  axes text doesn't appear in the box until I do
  159.  another  resize  that makes one of the axes larger! Clearly there's a solution
  160.  to the problem, since 1stword can handle that case.  I have tried all kinds of
  161.  tricks,  but  to  no  avail.   The  problem  is  easy enough to reproduce with
  162.  apskel.c  by inserting a call to v_text in the routine that does the painting.
  163.  I'm at my wit's end HHHHEEEEELLLLLLPPPPP!
  164.  
  165.       Anker
  166.  
  167.  
  168.       #: 11106 S2/GEM Support 05-Sep-86 20:24:35
  169.  
  170.  Fm: Anker Berg-Sonne 72337,3211       To: Anker Berg-Sonne 72337,3211
  171.       Of course I meant v_gtext() where I wrote v_text().
  172.  
  173.       Anker
  174.  
  175.  
  176.       #: 11113 S2/GEM Support 05-Sep-86 23:34:54
  177.  
  178.  Fm: Alan Page 72227,3507       To: Anker Berg-Sonne 72337,3211
  179.       GEM  doesn't seem to send redraw messages if you shrink a window, just if
  180.  you  enlarge  it.   My  solution  was  to check the size change when I get the
  181.  WM_SIZED  message,  and  if neither axis is being increased then send myself a
  182.  redraw  message  as  in  Tim  Oren's self_redraw code in the GEM tutorials.  -
  183.  Alan
  184.  
  185.  
  186.       #: 11111 S2/GEM Support 05-Sep-86 22:47:28
  187.  
  188.  Fm: NEIL R LINCOLN 73267,2265       To: Tim Oren 76703,202
  189.       An  obvious  but  maybe  gentle  reminder.  Before submitting bugs to the
  190.  compendium it would be helpful for contributors to check that the 'bugs' still
  191.  exist  in the current environments.  "Bugs" that i have cataloged in my system
  192.  have  disappeared  over time as various upgrades in software etc have occurred
  193.  
  194.  
  195.  
  196.        #11000-#GEM Bug List                                     Page -3-
  197.  
  198.  
  199.  
  200.  
  201.        #11000-#GEM Bug List                                     Page -4-
  202.  
  203.  
  204.  here.   Unfortunately  my  aged  memory  plays  tricks on me and I find myself
  205.  avoiding nonexistent or antiquated pitfalls.
  206.  
  207.  
  208.       #: 11116 S2/GEM Support 06-Sep-86 00:16:28
  209.  
  210.  Fm: Corey Cole 76224,66       To: Tom Jeffries 73717,2261
  211.       We have a kludgey solution -- depending on one of our state variables, we
  212.  either  use vq_mouse or graf_mkstate (the AES equivalent).  I have no idea why
  213.  vq_mouse  works  at some times and not at others, which makes me very nervous!
  214.  Fortunately,  at  least so far, the situations in which vq_mouse can't be used
  215.  are  also those in which response time is not critical.  You should stick with
  216.  graf_mkstate if you can handle the slow "feel".  - Corey
  217.  
  218.  
  219.       #: 11108 S0/General 05-Sep-86 20:25:17
  220.  
  221.  Fm: OZZIE BOESHANS 73157,2672       To: [F0] SYSOP 76703,2010
  222.       If  I  have a dialog box with a button in it and the button is defined as
  223.  an  EXIT  button  but not selectable, should pointing at it and clicking cause
  224.  form_do to want to be able to have a big button that I can click on and exit
  225.  from  form_do but I don't want it turned to reverse video when it is selected.
  226.  I  have found that unless the button is defined as EXIT and SELECTABLE form_do
  227.  does  not  exit  when the button it clicked.  Any ideas? Thanks in advance for
  228.  any help!
  229.  
  230.       Ozzie Boeshans 73157,2672
  231.  
  232.  
  233.       #: 11120 S2/GEM Support 06-Sep-86 03:27:52
  234.  
  235.  Fm: Don Curtis 76703,4321       To: SYSOP*Dave Groves 76703,4223
  236.       Dave,
  237.  
  238.       evnt_button(etc....)  locks  you in never-never land IF while waiting for
  239.  the  button  event,  you  move  the  mouse  into  the  menu  bar.   There is a
  240.  work-around,  you  do  an evnt_multi(etc...) looking for both the button event
  241.  AND  the  timer event with a time value of 1ms.  The C code for the workaround
  242.  goes like this:
  243.  
  244.       while(evnt_multi(MU_BUTTON | MU_TIMER, .etc...) == MU_TIMER);
  245.  
  246.       As  you can see, you will only exit this routine when the button has been
  247.  pressed.  Moving into the menu bar will not lock you with this work-around.
  248.  
  249.  
  250.  Don
  251.  
  252.       #: 11121 S2/GEM Support 06-Sep-86 05:07:00
  253.  
  254.  Fm: Dan Rhea 71777,2337       To: SYSOP*Dave Groves 76703,4223
  255.       Well  here's  one that has bothered me for a long time though it may be a
  256.  feature  rather  than  a  bug.   When  using a file selector box, and you have
  257.  selected a file at the bottom of the list (the slider has been moved down from
  258.  the  top).  You select the file and all is well.  Now you call up the selector
  259.  
  260.  
  261.  
  262.        #11000-#GEM Bug List                                     Page -4-
  263.  
  264.  
  265.  
  266.  
  267.        #11000-#GEM Bug List                                     Page -5-
  268.  
  269.  
  270.  again  but  this time you are sent back to the top of the selector and need to
  271.  go  searching for where you left off.  Is it possible for a selector box (even
  272.  optionally), to be able to remember its previous state.  Dan Rhea, 71777,2337
  273.  
  274.  
  275.       #: 11128 S2/GEM Support 06-Sep-86 12:30:24
  276.  
  277.  Fm: Stephen Mehalek 73277,2557       To: SYSOP*Dave Groves 76703,4223
  278.       The  modulus  operator that comes with VDIBIND library is incorrect.  The
  279.  lrem.o object module contains 144 bytes and produces results of zero when it is
  280.  used  to  give  the remainder of long integers.  The fix is to take the lrem.o
  281.  module  from  the GEMLIB object modules and move it to the VDIBIND libraries.
  282.  Use  the  AR^ AR68 utility routine to do this.  This bug is not a GEM bug, but
  283.  most people owning the developers package should know about this.
  284.  
  285.  
  286.       #: 11137 S2/GEM Support 06-Sep-86 18:30:21
  287.  
  288.  Fm: OZZIE BOESHANS 73157,2672       To: 76703,4224
  289.       Is there any way to keep a button in a DIALOG box from going reverse video
  290.  when it is selected?
  291.  
  292.       Also,  is  there  a way to set the state of the mouse buttons.  I have an
  293.  application that for some reason thinks the button is still down after a press
  294.  and release sometimes.  Pressing and releasing the button clears the condition.
  295.  What happens is that I select an option that causes a dialog box to appear and
  296.  once  in  a while when I move the mouse to a button the button becomes reverse
  297.  video  before  I  even  click.  If I move to a different button the new button
  298.  doesn't  turn  reverse  video but if I go back to the original it goes reverse
  299.  video.   If  I  click  anywhere  else on the screen and then reenter the first
  300.  button  it  no  longer  goes  reverse  video.  This really has me frustrated.
  301.  Thanks for any help that is given.
  302.  
  303.       Ozzie Boeshans 73157,2672
  304.  
  305.  
  306.       #: 11166 S2/GEM Support 07-Sep-86 21:01:48
  307.  
  308.  Fm: David Beckemeyer 74236,625       To: Corey Cole 76224,66
  309.       I've  noticed  that the lines between when you should (can) use VDI calls
  310.  and  when to use AES are somewhat fuzzy.  Is this documented anywhere that you
  311.  know of?
  312.  
  313.  
  314.       #: 11173 S2/GEM Support 07-Sep-86 22:32:42
  315.  
  316.  Fm: Corey Cole 76224,66       To: David Beckemeyer 74236,625
  317.       I  don't  know of any documentation on [when to use VDI vs.  AES calls].
  318.  In  general,  any display operation can use either/both, while input should be
  319.  restricted to one or the other (if the AES is used at all, your program should
  320.  only  do  input  with  AES  calls).   The catch is that AES is frequently less
  321.  efficient than VDI, sometimes (as with graf_mkstate) by major amounts.
  322.  
  323.  
  324.       #: 11167 S0/General 07-Sep-86 21:13:31
  325.  
  326.  
  327.  
  328.        #11000-#GEM Bug List                                     Page -5-
  329.  
  330.  
  331.  
  332.  
  333.        #11000-#GEM Bug List                                     Page -6-
  334.  
  335.  
  336.  Fm: David Beckemeyer 74236,625       To: Ric Clayton 73317,1350
  337.       Ric,  assuming  there isn't a simpler, plain old bug, in your program, it
  338.  looks  like  you may be running up against the classic GEMDOS getting confused
  339.  bug.
  340.  
  341.       I  have  seen  this  sort of problem, (GEMDOS unable to open, or create a
  342.  file for no apparent reason), and I have traced it some internal data structure
  343.  handling  bugs  in GEMDOS.  It seems than GEMDOS keeps a copy of the directory
  344.  tree structure of each disk, and as you access directories continually adds to
  345.  this  data  structure.   The  idea is to make file accesses faster by avoiding
  346.  reading each directory in the tree of a file spec whenever a file is accessed.
  347.  
  348.       So far so good, but under some circumstances, which seem to relate to the
  349.  number  of  directories accessed (across all drives), and I think also related
  350.  to  floppy disk media changes, this internal GEMDOS data structure gets messed
  351.  up,  and  GEMDOS doesn't know where to put the next link in its structure, and
  352.  goes out to lunch forever.
  353.  
  354.       I don't know the whole solution to this problem, b but I have been able to
  355.  reduce  its  frequency  by  making an undocumented BIOS call at certain times,
  356.  which  seems  to  force  GEMDOS  to  free some internal memory.  I found it by
  357.  catching the desktop making BIOS calls.  I don't have the code in front of me,
  358.  but  maybe  John Feagans @ Atari could help? If not, I'll look it up and leave
  359.  you a message.  - david
  360.  
  361.  
  362.       #: 11026 S0/General 04-Sep-86 01:31:42
  363.  
  364.  Fm: Ric Clayton 73317,1350       To: All
  365.       Hi there, I have written a program to backup files from my hard disk to a
  366.  floppy  disk  and  have  run  into  a problem I can't seem to get around.  The
  367.  program  is rather simple; it just copies files from a source directory to the
  368.  same  directory  on a designated floppy drive, creating directories as needed,
  369.  using GEMDOS calls.  Nothing fancy, just regular DOS type file copies.  So the
  370.  program goes chugging alone, happily copying files and all of a sudden gets an
  371.  "file  not  found"  error  (-33)  when  it  tries  to open the Source file for
  372.  reading,  the  name  of  which  it  just got from a directory scan! After this
  373.  occurs,  GEMDOS  seems  to  be  completely  dorked and strange things start to
  374.  happen,  requiring  a  re-boot  to  restore it to normalcy.  It doesn't always
  375.  happen,  and  when it does it's not always in the same place.  Sometimes I can
  376.  get  through a whole 5MB partition with no mishap.  Sometimes I can't even get
  377.  through  the  files in the root directory.  I have gone over and over the code
  378.  and  can't find any error that would cause this.  However, I'm new to both the
  379.  ST  and 'C' programming environments and may have made some false assumptions,
  380.  so  I'm  asking  for any help I can get.  I would be glad to upload the source
  381.  code  if  anyone  would  like to give it the go over.  The program doesn't use
  382.  GEM,  just  gemDOS (or is it TOS?).  (I've compiled it with Megamax-C and Mark
  383.  Williams C and get the same error.  Though I haven't tried Alcyon-C yet.)
  384.  
  385.       Thanks in advance for your help.
  386.  
  387.       Ric Clayton [73317,1350]
  388.  
  389.  
  390.       #: 11196 S2/GEM Support 08-Sep-86 12:30:21
  391.  
  392.  
  393.  
  394.        #11000-#GEM Bug List                                     Page -6-
  395.  
  396.  
  397.  
  398.  
  399.        #11000-#GEM Bug List                                     Page -7-
  400.  
  401.  
  402.  Fm: Jim Needhan, DRI 76703,1064       To: Corey Cole 76224,66
  403.       I  assume  the  confusion  is with "mouse" calls and the such...  The AES
  404.  should  always be used rather than the VDI when making mouse or other hardware
  405.  calls.   I have heard the complaints about speed but I do not fully agree with
  406.  those  programmer's  with  the  concerns.   I do realize that there is a speed
  407.  "hit"  but  what is gained is a program that is more reliable and more portable.
  408.  The AES cannot keep track of what the VDI is doing so by going through the AES
  409.  the "system" is aware of what is going on.
  410.  
  411.       Of  course,  you  may  write  directly to the VDI and in graphics display
  412.  calls  etc.   it is the correct path, but, for windowing, mouse control, etc.
  413.  it is better from the DRI point of view to go through the AES.
  414.  
  415.       Portability?  There  will  be  GEM  available for other environments, and
  416.  announcements  will  be  made as appropriate, so don't lock yourself out if it
  417.  isn't necessary.
  418.  
  419.       << jim >>
  420.  
  421.  
  422.       #: 11219 S2/GEM Support 08-Sep-86 22:13:27
  423.  
  424.  Fm: SYSOP*Tom Hudson 76703,4224       To: Jim Needhan, DRI 76703,1064
  425.       Right  you  are,  Jim.  The VDI mouse routines are great because they are
  426.  not  affected  by  the DCLICK speed setting, but the system goes "HUH?" if you
  427.  try  to intermix the VDI and AES mouse calls.  My solution: if you are doing a
  428.  mouse  operation  that  won't  be  declicked,  before the mouse is used set the
  429.  dclick  speed  to its fastest speed and restore it afterwards.  Thanks for the
  430.  help.
  431.  
  432.       Oh,  do  you  guys  have  any  information  on writing custom GDOS device
  433.  drivers  (like printers and custom screen devices)? If so, I'd like to get the
  434.  info if I may.  I'd appreciate it.
  435.  
  436.       -Tom
  437.  
  438.  
  439.       #: 11248 S2/GEM Support 09-Sep-86 01:10:50
  440.  
  441.  Fm: Corey Cole 76224,66       To: Jim Needhan, DRI 76703,1064
  442.       Jim,  I guess I didn't make myself totally clear.  When I was complaining
  443.  about  "speed  hits"  when using the AES to read the mouse, I didn't just mean
  444.  response  delays  (although  those  are  bad  enough).  We're talking actually
  445.  failing to recognize events -- for example, if the user presses the left mouse
  446.  button  in  an  application  using  graf_mkstate,  the application will not be
  447.  notified  unless  the  button  remains  depressed  for a sizable fraction of a
  448.  second.   I  believe  the  same is true with evnt_multi.  This behavior can be
  449.  seen  in  many  GEM  applications (Megamax editor, DEGAS, etc.) -- user has to
  450.  hold  down  the  button for about a second to get a new cursor (or whatever).
  451.  Highlighting (in FLASH, megamax editor, my word processor until I went over to
  452.  vq_mouse,  etc.)  also  "feels"  jerky  to  the user because the program isn't
  453.  immediately notified.
  454.  
  455.       At  the  GEM  seminar last year, I was told that evnt_multi does not wait
  456.  the  double-click  time  if  the  mouse  moves more than a pixel or two.  This
  457.  
  458.  
  459.  
  460.        #11000-#GEM Bug List                                     Page -7-
  461.  
  462.  
  463.  
  464.  
  465.        #11000-#GEM Bug List                                     Page -8-
  466.  
  467.  
  468.  simply  doesn't  seem  to  be  the case (it should be), in my observation.  In
  469.  general,  mouse  events  have a "clunky" feel to the user, which tends to hurt
  470.  the  "feel"  of  the  entire application.  Sorry to drag this into the ground,
  471.  just not sure how clearly I'm stating this! -- Corey
  472.  
  473.  
  474.       #: 11252 S2/GEM Support 09-Sep-86 03:23:11
  475.  
  476.  Fm: Alan Page 72227,3507       To: Corey Cole 76224,66
  477.       I  agree  with  you about the slowness of evnt_multi in picking up button
  478.  clicks.   Flash  1.1 uses a complicated kludge involving a mixture of vq_mouse
  479.  and  ev_mmobutton  which gives it _immediate_ response for cursor positioning.
  480.  - Alan
  481.  
  482.  
  483.       #: 11203 S2/GEM Support 08-Sep-86 13:18:40
  484.  
  485.  Fm: Mark Skapinker (BI) 76703,207       To: SYSOP*Dave Groves 76703,4223
  486.       Here are a few 'goodies' we know about:
  487.  
  488.       First some bugs:
  489.  
  490.       -If  you  use  a regular "form_do" in a desk accessory, you may find that
  491.  your keys 'fall through' to the application, so be prepared to write your own.
  492.  Falling  through  means  that  if  you  have a desk accessory on top of a word
  493.  processor  for example, keys pressed during a form in the desk accessory would
  494.  be picked up and used by the word processor.
  495.  
  496.       -Evnt_timer  is  a  very dangerous call to make from a desk accessory; it
  497.  sometimes  causes  the entire program to freeze up .  Regarding timers see the
  498.  following message from Chris.
  499.  
  500.       - The system exception handler has some bugs.  (See the following message
  501.  from Chris)
  502.  
  503.       -Appl_play and record do not work without an ROM patch from Atari.
  504.  
  505.       -Alcyon  Compiler  problems.   Appl_init  returns the wrong value (always
  506.  returns 1).
  507.  
  508.       -The  documentation  for  Vex_motv  is  wrong - it requires a jump to the
  509.  saved address to update the driver.
  510.  
  511.  
  512.  Some things to remember:
  513.       -Before  doing an fsel_input call, and before any I/O, make sure you have
  514.  set  path  names  (A:  is  not good enough, it must be A:\), or be ready for a
  515.  freeze.
  516.  
  517.       -Form_alert strings can only be about 30 characters per line.
  518.  
  519.       -You   should  modify  the  source  of  form_do  (form_keybd)  to  change
  520.  underscores to dashes; underscores blows your application out of the water.
  521.  
  522.       Mark
  523.  
  524.  
  525.  
  526.        #11000-#GEM Bug List                                     Page -8-
  527.  
  528.  
  529.  
  530.  
  531.        #11000-#GEM Bug List                                     Page -9-
  532.  
  533.  
  534.  
  535.       #: 11204 S2/GEM Support 08-Sep-86 13:20:55
  536.  
  537.  Fm: Mark Skapinker (BI) 76703,207       To: SYSOP*Dave Groves 76703,4223
  538.       There are 2 serious bugs related to desk accessories.  Both were reported
  539.  to Atari months ago.
  540.  
  541.  
  542.  1.  EVNT_TIMER is flaky.  The timer event will not always return when called.
  543.  This  seems  to  happen  most often when there is heavy disk activity, but not
  544.  always.   If  you do an evnt_multi() with messages and timers, the timers will
  545.  eventually  hang up, but if the accessory receives a message, the timers start
  546.  working  again  (for  a  while).   We  call  this  burping  the  timer.   As a
  547.  programmer,  this  means  that  you  must  find  an alternate way of releasing
  548.  control  (it isn't easy).  That's why some desk accessories degrade the system
  549.  performance  so  much.   This  bug  has been ported from the IBM PC version of
  550.  GEM.
  551.  
  552.  2.   The  system  exception  handler  has one or more bugs.  If an application
  553.  generates  a  system  alert  (drive  not  responding, insert your new A: disk,
  554.  etc.),  any  desk  accessory  that is running is not stopped.  That is, if you
  555.  have an accessory buzzing along waiting for evnt_timers (which you shouldn't),
  556.  or  mouse  movement events (actually any evnt_ function has this problem), the
  557.  multitasking  of  the  desk  accessories  is not turned off while the alert is
  558.  presented.   I  checked this out with an accessory that woke up constantly and
  559.  wrote  a  counter  to  the  screen.  As soon as the alert is cleared, the desk
  560.  accessory,  then  the  application bomb.  I suspect it's because the accessory
  561.  gets  running  in  supervisor  mode and messes up the super stack or something
  562.  like  that.   The  same  thing can happen in a one drive system in another way
  563.  (this is probably a separate bug).  If the desk accessory reads from drive B:,
  564.  and  the  system  alert  is  generated  to  swap diskettes, after the alert is
  565.  cleared  first  the desk accessory then the application will bomb.  We've even
  566.  seen it bomb the GEM Desktop.-- Chris Bailey (Batteries Included)
  567.  
  568.       #: 11232 S2/GEM Support 08-Sep-86 23:33:36
  569.  
  570.  Fm: Rich Plom (Intersect) 73307,1676       To: SYSOP*Dave Groves 76703,4223
  571.       You  want  bugs,  use  the  file  selector.  It is one of the most flawed
  572.  things  in  the  system.  You can crash it two ways, put the '_' in the path.
  573.  Or,  you can just leave a disk out and wait two times for it to give the abort
  574.  continue  error,  after that booomb! Also, when you have a single drive system
  575.  and you try to treat drive b as disk b, he really gets strange.
  576.  
  577.       - Rich
  578.  
  579.  
  580.       #: 11267 S2/GEM Support 09-Sep-86 11:39:02
  581.  
  582.  Fm: Ken Settle 76556,753       To: SYSOP*Dave Groves 76703,4223
  583.       I  have  noticed  the  following  bugs in GEM: Bug series #1: (AES object
  584.  library section)
  585.  
  586.       In  the  TEDINFO  structure,  te_pvalid  field,  the following validation
  587.  characters  DO  NOT work properly: 9, A, a, N, n, P, p, (all except F and X).
  588.  The bug occurs when a form_dial is called with an object containing any of the
  589.  
  590.  
  591.  
  592.        #11000-#GEM Bug List                                     Page -9-
  593.  
  594.  
  595.  
  596.  
  597.        #11000-#GEM Bug List                                     Page -10-
  598.  
  599.  
  600.  above  characters in the PVALID field.  If the user types an underscore "_" on
  601.  any  character  position  (except the last), the system promptly "bombs" out.
  602.  The  bug with the "F" character in that situation was fixed in ROM TOS and the
  603.  "X" character never had this problem (to my knowledge).
  604.  
  605.       Also  in  the  TEDINFO structure, the te_txtlen and te_tmplen fields both
  606.  contain   the   length+1   of   their  respective  strings,  contrary  to  the
  607.  documentation.
  608.  
  609.       Bug series #2: (GEMDOS section)
  610.  
  611.       Hard disk file WRITE time increases by roughly 1 second for each megabyte
  612.  stored  on  that  drive  (partition,  whatever).   This  is  probably  due  to
  613.  unspeakably slow FAT search code (it takes about 450 times as long as it would
  614.  using two simple 68000 instructions to search a FAT sector).
  615.  
  616.       Dfree() command takes "next to forever" on the hard drive.
  617.  
  618.       It  is  somehow  possible  to  get  a  folder  (on the hard disk) that is
  619.  impossible to delete, even though it's empty.  - Ken Settle [76556,753]
  620.  
  621.  
  622.       #: 11268 S2/GEM Support 09-Sep-86 11:42:38
  623.  
  624.  Fm: Ken Settle 76556,753       To: Ken Settle 76556,753
  625.       Bug series #3: (GEM Desktop section)
  626.  
  627.       SOMETIMES  when  you close a directory window and re-open it from another
  628.  drive,  the  window decides to exactly cover up the top window on the screen.
  629.  This  has  been  a  major  annoyance causing me to be paranoid about closing a
  630.  directory window.  It seems ïo∞be very random (as all truly good bugs are).
  631.  
  632.       Changing  resolution  and/or  colors can really screw up the desktop when
  633.  you  return  to  it.  It shÉuôd be Desktop's responsibility to make sure these
  634.  conform  to  the  current defaults.  Desktop should also automatically set ALL
  635.  DESKTOP.INF  defaults  on∞ Åower up, and allow ANY application or accessory to
  636.  have  access  to/modify  these  defaults  (palette,  key  rate, RS232/Printer
  637.  setup).
  638.  
  639.       Desktop∞ îhould  be hardy enough to survive a "close workstation" call by
  640.  an  application,  without losing it's "pull-down menu" capability.  This might
  641.  allow  VDI∞ ïo  be  used in any resolution as dictated by the application, not
  642.  desktop.
  643.  
  644.       It  should  be possible to abort a multiple-file COPY or DELETE operatiÉn≥
  645.  at any time using the mouse and/or keyboard.
  646.  
  647.       Bug series #4: ("TOS" section)
  648.  
  649.       An error box stating "TOS ERROR #35" means nothing to most people, what's
  650.  the real message?
  651.  
  652.       Bug series #5: (AES/VDI section)
  653.  
  654.       The  dot-pattern  in  the  move  bar  of a window can get screwed up by a
  655.  
  656.  
  657.  
  658.        #11000-#GEM Bug List                                     Page -10-
  659.  
  660.  
  661.  
  662.  
  663.        #11000-#GEM Bug List                                     Page -11-
  664.  
  665.  
  666.  redraw  attempt  such as after a dialog has disappeared.  It appears to happen
  667.  because  of  the  "blit"  feature  being  used  to  move  a  window to any odd
  668.  line/pixel  where  VDI  can't  accurately  match up the pattern.  - Ken Settle
  669.  [76556,753]
  670.  
  671.  
  672.       #: 11307 S2/GEM Support 10-Sep-86 00:26:44
  673.  
  674.  Fm: Dan Rhea 71777,2337       To: SYSOP*Dave Groves 76703,4223
  675.       Here  is  another interesting one I've stumbled on.  It is not a "GEM" bug
  676.  but  a  bug  in the C Runtime (GEMLIB), or the AS68.PRG step of the latest and
  677.  greatest  compiler.   This has been driving me nuts till I finally isolated it
  678.  to the following test case.  The test works fine with the old compiler/runtime
  679.  but  gives  bad results for the new one (i.e.  every other long has a value of
  680.  0).  main()
  681.  
  682.       {
  683.  
  684.       long int a, b, c, d; int i; a = b = c = d = 0L;
  685.  
  686.       for (i=0; i<25; i++)
  687.  
  688.       { a++; b++; c++; d++;
  689.  
  690.       printf ("a=%D b=%D c=%D d=%D\n",a,b,c,d);
  691.  
  692.       }
  693.  
  694.       Cconin (); /* Wait for any character */
  695.  
  696.       }
  697.  
  698.  
  699.  Good Results: a=1 b=1 c=1 d=1
  700.       a=2 b=2 c=2 d=3
  701.  
  702.       ...
  703.  
  704.       a=25 b=25 c=25 d=25
  705.  
  706.       Bad Results a=1 b=0 c=1 d=0
  707.  
  708.       a=2 b=0 c=2 d=0
  709.  
  710.       ...
  711.  
  712.       a=25 b=0 c=25 d=0
  713.  
  714.  
  715.  Note:  I  included OSBIND.H in the above program too.  Has anyone hit this one
  716.  yet  or  devised  a  workaround  (other than floating point or the obvious two
  717.  longs for each one used).  Dan Rhea, 71777,2337
  718.  
  719.       #: 11314 S2/GEM Support 10-Sep-86 09:38:33
  720.  
  721.  
  722.  
  723.  
  724.        #11000-#GEM Bug List                                     Page -11-
  725.  
  726.  
  727.  
  728.  
  729.        #11000-#GEM Bug List                                     Page -12-
  730.  
  731.  
  732.  Fm: Mark Skapinker (BI) 76703,207       To: SYSOP*Dave Groves 76703,4223
  733.       Dave,  As the GEM DESKTOP is simply a 'program' , I think its bugs should
  734.  be kept separate.
  735.  
  736.       Mark
  737.  
  738.  
  739.       #: 11310 S2/GEM Support 10-Sep-86 00:43:55
  740.  
  741.  Fm: Rich Plom (Intersect) 73307,1676       To: SYSOP*Dave Groves 76703,4223
  742.       Nope, the only way around them is to write your own file selector.  Atari
  743.  will  someday weed the bugs out(hopefully).  It is a shame that a solid program
  744.  can  be  crashed by it.  It looks like the authors fault to everyone else, but
  745.  the blame is the operating systems.  The one that gets me the most is when you
  746.  forget  to  put  a  disk  in or put it in crooked and it dies after the second
  747.  retry.
  748.  
  749.  
  750.       #: 11443 S2/GEM Support 12-Sep-86 00:14:24
  751.  
  752.  Fm: Tom Jeffries 73717,2261       To: Jim Needhan, DRI 76703,1064
  753.       There's  an  old  rule of thumb- if one person tells you you have a tail,
  754.  don't  bother  to  look.  If ten people tell you you have a tail, you'd better
  755.  take  a  look  to see what's going on.  Actually, I think most of us look when
  756.  one  person  tells us we have a bug.  There is a whole series of problems with
  757.  reading  the  mouse  which  include:  slow and inaccurate reading of the mouse
  758.  buttons,  especially  from  the  AES,  evnt_multi()  will  not read both mouse
  759.  buttons  (as  far as I know that's not in the bug list yet, we should add it),
  760.  mouse  button  releases  are  not  always recognized, etc.  etc.  etc.  I must
  761.  admit  I'm  getting  a  little  tired  of  DRI and Atari trying to blame these
  762.  problems on bad code.  Too many developers are having the same problems for it
  763.  to  be  bad code.  In an earlier note, you defend the slowness of evnt_multi.
  764.  If  it really were accurate, I might go along.  However, even if that were the
  765.  case,  it  is  hard  to  ignore  the fact that the Mac, which also has to read
  766.  double  clicks,  feels much less clunky than the ST.  GEM, like all operating
  767.  systems, has some problems.  Actually, if you compare it with MS-DOS, which is
  768.  much simpler but also has lots of bugs, you guys at DRI and the folks at Atari
  769.  did a terrific job, especially considering the time it took to get the machine
  770.  on the market.  No purpose is served, however, by trying to blame bad code for
  771.  problems  that  are real and don't seem to be getting solved.  I don't mean to
  772.  cause  offense- but since we have the benefit of having some of the people who
  773.  wrote  GEM  online,  I  would like the discussion to be at a realistic level.
  774.  Thanks,
  775.  
  776.       Tom Jeffries
  777.  
  778.  
  779.       #: 11445 S2/GEM Support 12-Sep-86 00:18:23
  780.  
  781.  Fm: Tom Jeffries 73717,2261       To: Mark Skapinker (BI) 76703,207
  782.       One  more  bug-  despite the documentation, you cannot read both the left
  783.  and  the  right mouse button with one evnt_multi() call.  You have to use two,
  784.  which  gives  you  time  to go out for dinner before the mouse button event is
  785.  reported, or use a different call.
  786.  
  787.  
  788.  
  789.  
  790.        #11000-#GEM Bug List                                     Page -12-
  791.  
  792.  
  793.  
  794.  
  795.        #11000-#GEM Bug List                                     Page -13-
  796.  
  797.  
  798.  
  799.       #: 11456 S2/GEM Support 12-Sep-86 16:24:52
  800.  
  801.  Fm: Michael T.  Smith 73317,3470       To: Mark Skapinker (BI) 76703,207
  802.       OK,  I want in this mesh of messages...  I just yesterday started writing
  803.  a ml routine to be used in the vex_motv function.  I had heard of some bugs in
  804.  the  vq_mouse and my program has been slipping in the area of mouse handling..
  805.  So,  the  problem occurred when it hits the vex_motv it gives me 2 bombs and i
  806.  don't know why, I haven't looked on Dl2 yet but I will to see if my problem can
  807.  be  answered  there.   (  I  think  thats  where  you  were  going  to put the
  808.  compiled list of bugs) If its simply in MY ml code then I will eventually
  809.  find  it,  but if there is funny business in that routine I would like to know
  810.  how  to  get  around  it.  The only other thing I think I'll be able to answer
  811.  myself:  Desk Acc's.  I know that if I get a message 20 then I need to redraw.
  812.  Is  that  It?  If you have any Advice simply give it.  I appreciate you help.
  813.  Thanks....  Michael T Smith Xetec Inc.  Salina Ks 73317,3470
  814.  
  815.  
  816.       #: 11483 S2/GEM Support 13-Sep-86 10:55:39
  817.  
  818.  Fm: Tom Jeffries 73717,2261       To: Michael T.  Smith 73317,3470
  819.       One  more  bug  (There's always one more bug), I think this one is pretty
  820.  well known and documented but it can be unpleasant if you don't know about it:
  821.  fsel_input()  resets  the  clipping  rectangle and does not reset it on exit.
  822.  It's  easy to work around- you just set your own clipping area when you regain
  823.  control.
  824.  
  825.  
  826.       #: 11539 S2/GEM Support 13-Sep-86 22:58:44
  827.  
  828.  Fm: Alan Page 72227,3507       To: [F7] SYSOP*Dave Groves 76703,4223
  829.       Here's another bug for the list.  When I use the function appl_find (from
  830.  a  desk  accessory)  it  should  return  -1  if the application is not found.
  831.  However, if I call appl_find with the name of an application just after I exit
  832.  it,  I  get a 'valid' ID.  As soon as I run another application then I get the
  833.  proper  -1  value  returned.   It acts like the name of the application is not
  834.  erased until you run another application.  - Alan
  835.  
  836.  
  837.       #: 11540 S2/GEM Support 14-Sep-86 01:37:43
  838.  
  839.  Fm: SYSOP*Tom Hudson 76703,4224       To: [F7] Alan Page 72227,3507
  840.       By  golly,  Alan  --  you have the same bug as I found yesterday!!! I was
  841.  working  on  a  desk  accessory that looked for DEGAS Elite, and it works fine
  842.  until Elite is run.  That is, it knows it's not there before Elite is run, but
  843.  thinks it's there after Elite's done! Fortunately, The accessory is written so
  844.  that that does not matter, but it is a bug that should be reported.
  845.  
  846.       -Tom
  847.  
  848.  
  849.       #: 11641 S2/GEM Support 16-Sep-86 08:47:54
  850.  
  851.  Fm: Michael T.  Smith 73317,3470       To: SYSOP*Russ Wetmore 76703,2010
  852.       Russ,  Thanks  for the info..  I am using the 'asm{...}' from megamax for
  853.  
  854.  
  855.  
  856.        #11000-#GEM Bug List                                     Page -13-
  857.  
  858.  
  859.  
  860.  
  861.        #11000-#GEM Bug List                                     Page -14-
  862.  
  863.  
  864.  my  interrupt interrupt but also 'C'...  mint() { asm{...} }.  The problem now
  865.  exists  that  as  soon as I call the vex_motv(num1,,); it crashes (2 bombs:Bus
  866.  error)  then  returns  to the desktop where it sits until I move the mouse and
  867.  then  I get 4 bombs..  (Illegal inst.) Currently, my int.  is only a nop which
  868.  leads  me  to  believe  that  it is not caused by my int.  but by the way I am
  869.  calling  the  vex_motv();.  I saw something about having to call , or jump to,
  870.  the  location  that thee function returns to you.  Also I noticed once that it
  871.  executed the next 'C' instruction after the vex_motv.  Go FIgure? Well, if any
  872.  of this sounds familiar than let me know.  Michael T Smith...  Xetec Inc.
  873.  
  874.  
  875.       #: 11667 S2/GEM Support 16-Sep-86 22:23:41
  876.  
  877.  Fm: SYSOP*Russ Wetmore 76703,2010       To: Michael T.  Smith 73317,3470
  878.       There's  an example of calling vex_timv in DL0 someplace that I uploaded.
  879.  The  procedure  should be similar for vex_motv if you'd like to look at it.  [
  880.  Russ ]
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898.  
  899.  
  900.  
  901.  
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.        #11000-#GEM Bug List                                     Page -14-
  923.  
  924.  
  925. əəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəəə